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Abstract 


This  report  summarizes  the  results  of  a  workshop  focused  on  requirements  man¬ 
agement  in  a  system  of  systems.  The  workshop  attendees  were  affiliated  with  the 
Army  Program  Executive  Office  (PEO)  Aviation  and  T raining  and  Doctrine  Com¬ 
mand  (TRADOC)  Combat  Developers.  During  the  workshop,  issues  were  identi¬ 
fied  in  a  number  of  areas,  including  requirements  management,  system-of- 
systems  management,  and  system  construction.  Many  of  the  issues  raised 
address  some  form  of  the  conflict  that  exists  between  a  top-down,  policy  driven 
approach  to  the  acquisition  of  a  system  of  systems  and  a  bottom-up,  program-cen¬ 
tric  approach  to  the  acquisition  of  an  individual  system. 
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1  Introduction 


This  note  describes  the  results  of  a  workshop  focused  on  issues  related  to  require¬ 
ments  management  for  a  system  of  systems  (SoS).  The  workshop  was  held  at  Ft. 
Rucker,  Ga.,  on  September  13-14,  2005. 1  n  the  workshop,  issues  also  surfaced 
about  the  acquisition  and  construction  of  an  SoS.  Some  analysis  of  the  issues  was 
performed  with  the  attendees  during  the  workshop;  however,  most  of  the  analysis 
was  conducted  fol  I  owi  ng  the  workshop. 

As  background,  a  definition  of  the  term  system  of  systems  is  relevant;  the  follow¬ 
ing  is  from  the J  oint  Capabilities  I  integration  and  Development  System  (J  Cl  DS): 

system  of  systems  (SoS):  A  set  or  arrangement  of  interdependent  systems  that 
are  related  or  connected  to  provide  a  given  capability.  The  loss  of  any  part  of  the 
system  will  significantly  degrade  the  performance  or  capabilities  of  the  whole.  The 
development  of  a[n]  SoS  solution  will  involve  trade  space  between  the  systems  as 
well  as  within  an  individual  system  performance.  An  example  of  a[n]  SoS  would  be 
a  combat  aircraft.  While  the  aircraft  may  be  developed  as  a  single  system,  it  could 
incorporate  subsystems  developed  for  other  aircraft.  For  example,  the  radar  from 
an  existing  aircraft  may  be  incorporated  into  the  one  being  developed  rather  than 
developing  a  new  radar.  The  SoS  in  this  case  would  be  the  airframe,  engines, 
radar,  avionics,  etc.  that  make  up  the  entire  combat  aircraft  capability  [JCS  05]. 

A  related  term  is  family  of  systems  (FoS);  however,  no  distinction  between  these 
two  terms  was  made  at  the  workshop.  These  terms  are  further  di  scussed  i  n 
Appendix  A. 

This  report  is  organized  in  the  fol  I  owing  manner: 

■  Secti  on  2  descri  bes  the  approach  taken  i  n  the  workshop. 

■  Section  3  presents  the  issues  elicited  and  an  initial  categorization  of  them. 

■  Section  4  presents  an  analysis  of  the  issues. 

■  Section  5  discusses  the  relation  between  the  issues  identified  in  this  workshop 
and  those  of  a  previous  workshop. 

■  Section  6  contains  a  brief  summary  of  the  report. 

■  Appendices 

-  Appendix  A  examines  the  terms  system  of  systems  and  family  of  systems. 
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-  AppendixB  provides  an  alternativeview  of  requirements  management  in 
a  system-of-systems  context. 

-  Appendix  C  provides  a  brief  list  of  typical  activities  associated  with 
requirements  management. 

-  Appendix  D  contains  a  discussion  of  workshop  attendees  regarding  the 
Army  Software  Blocking  policy. 

-  AppendixE  provides  an  example  in  the  development  of  patterns  from  the 
attendee  issues. 

-  A  list  of  acronyms  is  in  Appendix  F . 
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2  Workshop  Approach 


2.1  Purpose  and  Scope 

The  major  purpose  of  the  workshop  was  to  elicit  and  analyze  issues  associated 
with  requirements  management  for  an  SoS.  A  bri  ef  descri  pti  on  of  the  traditional 
requirements  management  approach  appears  in  Appendix  C.  Differences  in 
approach  are  introduced  when  one  considers  an  SoS;  an  alternative  perspective 
on  requirements  in  the  system-of-systems  context  appears  in  Appendix  B.  Any 
distinction  in  scope  of  requirements  discussed  at  the  workshop  was  recognized  by 
noting  the  context  of  use  (e.g.,  a  system-of-systems  requirement  or  a  system 
requirement). 

The  major  activities  of  the  workshop  were  to 

■  have  the  attendees  devel  op  a  context  di  agram  for  requi  rements  manage¬ 
ment— a  diagram  showing  actors  and  their  interactions1 

■  elicit  attendee  issues  and  then  relate  them  to  the  context  diagram 

A  simple  example  of  a  context  diagram  for  the  requirements  management  process 
for  an  SoS,  as  presented  to  the  attendees,  is  shown  in  Figure  1.  The  example  here 
i  s  very  si  mpl  e  i  n  compari  son  to  the  actual  system-of-systems  envi  ronment;  how¬ 
ever,  such  simplification  can  provide  useful  insights,  assuming  the  data  used  to 
construct  the  diagram  is  sufficiently  grounded  in  real  experience.  This  figure 
shows  two  program  management  organizations  (PMOs),  PMO-A  and  PMO-B, 
engaged  in  an  acquisition.  Each  PMO  has  an  associated  milestone  decision 
authority  (M  DA),  and  a  prime  contractor  (possibly,  subcontractors  as  well)  for  the 
development  of  the  individual  systems.  TheJ  oint  Requirements  Oversight  Coun¬ 
cil  (J  ROC)  is  also  included  because  of  its  role  in  the  requirements  process.  Thus, 
Figure  1  illustrates  a  context  diagram  that  could  be  used  to  frame  the  discussion 
for  issues  identified  by  attendees. 


1  The  term  actor  is  used  to  indicate  any  organization  or  thing  that  affects  requirements 
management;  thus,  actors  may  include  people,  organizations,  standards,  or  commercial 
off-the-shelf  (COTS)  products.  I  n  other  words,  actors  include  more  than  stakeholders. 
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Figure  1:  A  Simple  Context  Diagram 


Another  purpose  of  the  workshop  was  to  identify  interoperability  considerations 
presented  by  the  attendees.  This  was  done  in  the  context  of  the  System-of-Sys- 
tems  I  nter  operability  (SOSI )  model.  A  key  aspect  of  the  SOSI  model  is  that 
interoperability  comes  in  various  flavors.  While  traditionally  considered  in  the 
context  of  an  operational  system,  the  SOSI  model  also  includes  programmatic 
aspects,  as  well  as  consideration  of  how  system(s)  are  constructed.2  This  subject  is 
discussed  in  Proceedings  oftheSystem  ofSystemsInteroperability  Workshop  (Feb¬ 
ruary  2003)  [Levine  03]  and  System  of  Systems  I  nter  opera  bi  I  ity  (SOSI);  Final 
Report  [Morris  04], 


2  Very  loosely  speaking,  interactions  between  the  PMOs  are  mainly  an  exampleof  pro¬ 
grammatic  interoperability,  while  interactions  between  the  prime  contractors  can  be 
viewed  as  an  exampleof  constructive  interoperability. 
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2.2  Attendees 

The  workshop  attendees  came  from  various  U.  S.  Army  (Army)  organizations, 
reflecting  significant  breadth  and  depth  of  acquisition  and  user  experience. 
Attendees  were  combat  and  materiel  developers  from  USAAWC  DCD  and  PEO 
Aviation. 3These  included  active  duty  military,  government  civilian,  and  contrac¬ 
tor  personnel  with  a  wide  range  of  operational  user  and  requirement  system  expe¬ 
rience. 

2.3  Initial  Plan 

The  planned  agenda  for  the  workshop  is  summarized  below: 

■  Introduction 

■  Attendee  Presentations:  allow  attendees  to  present  their  organization  con¬ 
texts 

■  Background  on  Requirements  Management:  describe  the  role  of  requirements 
management 

■  I  ssue  Elicitation:  allow  attendees  to  discuss  their  three  most  significant  issues 
for  prioritization  by  the  group 

■  Context  Discussion:  identify  actors,  their  relationships,  and  attendee  develop¬ 
ment  of  context  diagram(s) 

■  Relating  I  ssues  to  Context  Diagram:  examine  issues  identified  by  attendees  to 
see  how  issues  relate  to  the  context  diagram 

■  I  ntroduction  to  SOSI  model:  define  a  context  for  interoperability  discussions 

■  Decomposition  of  Issues:  use  the  SOSI  model  as  a  basis  for  discussing  various 
issues  related  to  interoperability  regarding  requirements  management— with 
the  goal  of  identifying  the  programmatic,  constructive,  and  operational 
aspects 

■  N  ext  Steps:  enumerate  the  next  steps  recommended  by  the  attendees 

■  Summary  and  Action  Review 


2.4  Conduct  of  the  Workshop 

The  actual  conduct  of  the  workshop  deviated  from  the  plan  for  several  reasons, 
including: 


3  A  list  of  acronyms  appears  in  Appendix  F. 
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■  During  the  attendee  presentations,  a  number  of  issues  were  raised.  However, 
the  issues  were  not  placed  in  an  overall  context  that  was  explicit  to  all  of  the 
attendees. 

■  There  were  concerns  about  the  context  di  agram.  Several  attendees  poi  nted  out 
that  a  full  specification  of  the  context  diagram  would  be  quite  a  large  under¬ 
taking.  For  future  workshops,  an  alternative  might  be  to  bring  in  a  specifica- 
ti  on  of  the  context  di  agram  pri  or  to  conducti  ng  the  workshop. 

■  A  majority  of  the  attendees  had  to  leave  after  the  first  day,  although  several 
were  kind  enough  to  participate  by  a  tel  con  on  the  second  day. 

■  There  was  discussion  of  the  Army  software  blocking  policy  at  various  times 
during  the  workshop.  Such  discussion  was  not  included  in  the  analysis,  but 
the  discussion  points  were  captured  and  appear  in  Appendix  D. 

After  completing  about  half  of  the  planned  agenda,  we  made  a  change.  I  n  particu¬ 
lar,  following  issue  elicitation  and  prioritization,  we  examined  the  higher  priority 
i  ssues.  We  sought  to  determi  ne  the  actors  rel  evant  to  an  i  ssue  and  the  rel  ati  ons 
among  the  actors.  Whiletheterm  interoperability  often  came  up,  we  held  no  dis¬ 
cussion  of  the  issues  in  terms  of  the  various  forms  of  interoperability.  Despitethe 
adjustment  in  approach,  much  valuable  information  was  gathered.  The  issues 
rai  sed  are  descr i  bed  i  n  Secti  on  3.  There  was  i  nsuffi  ci  ent  ti  me  or  attendees  present 
to  discuss  possible  next  steps. 


2.5  Considerations  for  Future  Workshops 

The  need  to  change  from  the  planned  approach  raises  issues  for  the  future  con¬ 
duct  of  workshops  that  are  si  mi  I  ar  i  n  i  ntent  to  the  one  descri  bed  here.  I  n  some 
sense,  the  planned  approach  had  a  top-down  view,  while  the  conduct  of  the  work¬ 
shop  was  bottom-up.4  Among  the  issues  regarding  the  conduct  of  the  workshop, 
the  fol  I  owi  ng  are  rel  evant: 

■  How  should  the  context  diagram  be  presented?  The  context  di  agram  hel  ps  to 
identify  actors  and  their  relations  and  allows  for  shared  understanding  of 
some  domain.  The  original  plan  was  to  have  such  a  diagram  developed  by  the 
attendees  to  gain  their  perspective  of  the  context.  (There  may  be  a  difference 
between  the  ways  thi  ngs  are  supposed  to  be  and  the  way  they  are!)  As  poi  nted 
out  previously,  there  were  concerns  about  the  size  and  complexity  of  the  con- 


4  We  use  the  terms  top  down  and  bottom  up  to  refer  to  alternative  approaches.  The 
former  refers  to  the  development  of  a  context  diagram  for  relevant  aspects  of  acquisi¬ 
tion  prior  to  discussion  of  issues,  and  the  latter  refers  to  elicitation  of  issues  prior  to 
developing  a  context  diagram. 
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text  diagram.  An  alternative  may  be  to  have  the  attendees  present  their 
issues;  the  relevant  context  diagram  can  then  be  developed  after  the  work¬ 
shop. 

■  Would  an  issue-first  approach  beviable?Such  an  approach  was  followed  at  the 
workshop  without  the  prior  development  of  the  context  diagram.  It  seemed  to 
work  well  in  terms  of  the  information  elicited.  The  detriment  of  such  an 
approach  is  the  lack  of  an  "integration  harness"  in  which  to  address  issues. 

■  Should  the  workshop  I ength  be  i n creased,  perhaps  to  two  or  two-and-a-hal  f 
days? There  is  opportunity  for  information-gathering  and  analysis  at  the 
workshop.  However,  it  is  difficult  for  attendees  to  spend  even  more  than  a  day 
at  such  an  event. 

■  Should  theworkshop  beconducted  as  a  seri es  of  i nteracti ons?  For  example,  the 
first  interaction  would  bean  elicitation  and  exploration  of  the  issues.  Then, 
the  context  diagram  would  be  developed  offline.  A  second  interaction  would  be 
the  presentation  of  the  context  diagram  to  the  attendees,  from  which  further 
discussion  would  ensue. 

Regardless  of  the  structure  and  conduct  of  the  workshop,  the  intended  goals  must 
be  kept  in  mind.  Several  choices  are  possible.  One  goal  might  be  to  develop  the 
context  diagram  for  some  system-of-systems  topic,  such  as  requirements  manage¬ 
ment.  Another  goal  might  be  to  identify  issues  relative  to  some  particular  topic. 
Still  another  goal  might  be  some  combination  of  those  goals.  In  any  case,  an 
understanding  of  the  issues  is  necessary  to  develop  a  solution  approach. 
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3  Identification  of  Issues 


The  foil  owing  list  presents  the  issues  as  developed  by  the  workshop  attendees. 

The  issues  are  presented  in  the  form  "condition^  consequences"  (Hence  the 

character  may  be  read  as  "therefore.")  The  issues  are  listed  in  prioritized  order, 

from  highest  to  lowest,  as  determined  by  the  attendees. 

1.  There  is  no  system  engineering  staff  above  the  program  manager  (PM)  level 
(e.g.,  Army  or  DoD);  this  results  in  multiple  solutions  (stovepipes),  subopti¬ 
mized  (at  a  lower  level)  for  similar  problems— systems-of-systems  hierarchy 
is  missing. 

2.  System-of-systems  requirements  are  not  clearly  documented  or  configuration 
controlled/managed;  they  cannot  be  further  allocated,  derived,  or  met. 

3.  The  system-of-systems  user  combat  requirement  developer  is  not  clearly 
chartered;  cannot  derive  a  single  set  of  requirements. 

4.  System-of-systems  policy  and  mandates  are  without  incentives  and  enforce¬ 
ment;  does  not  ensure  change  from  stovepi  pe  to  SoS. 

5.  The  Planning,  Programming,  Budgeting  and  Execution  System  (PPBES)  is 
not  synchronized  with  the  realities  of  system-of-systems  acquisition;  the 
resources  required  are  not  in  the  right  place  at  the  right  time  (event-driven 
versus  a  time-driven  process  conflict). 

6.  There  is  no  method  for  validating  and  adjudicating  interoperability  require¬ 
ments  in  the  documentation  process;  interoperability  requirements  are  not 
defined  early  or  identified  as  a  common  development  goal. 

7.  There  is  no  ownership  of  system-of-systems  requirements;  there  is  no  follow¬ 
up  for  their  explanation  or  verification. 

8.  There  is  no  single  funding  line  for  system  of  systems;  cannot  bring  personnel, 
resources,  and  priorities  together  sufficiently  to  develop  the  common  require¬ 
ments. 

9.  The  general  system-of-systems  procedure  currently  in  place  does  not  produce 
effective  results;  there  is  a  need  for  a  process  that  is  comprehensive,  to 
include  time  frame,  management  structure,  definition  of  terms,  results,  and 
responsibilities. 

10.  TheJ  Cl  DS  process  has  no  path  that  leads  to  a  view  (architecture)  that  can  be 
used  for  a  statement  of  specification  for  a  material  developer  or  test  criteria 
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by  the  combat  devel oper;  there  i s  no  di red  link  from  requi rements  to  end 
produd. 

11.  The  Army  has  no  tools  (more  automated  than  Excel,  a  protocol  checker)  to 
adequately  model  interoperability;  must  wait  until  done  to  achieve  interoper¬ 
ability  by  trial  and  error. 

12.  There  is  a  lack  of  application  of  system  engineering  to  capability  development 
and  gap  analysis  (science  and  technology);  multiple  organizations  (uncoordi¬ 
nated)  working  on  multiple  solutions  to  solve  either  the  same  problem  or  sim¬ 
ilar  problems. 

13.  There  are  insufficient  resources  for  requirements  development  and  manage¬ 
ment;  shortcuts  are  taken  and  key  aspeds  may  be  missed. 

14.  System-of-systems  lessons  learned  and  "good  idea"  insertion  are  not  incorpo¬ 
rated  and  managed;  the  benefit  of  experience  and  impad  of  requirement 
creep  are  not  considered. 

15.  DoD  maintains  multiple  systems  with  independent  users,  requirements,  and 
timelines  with  no  single  authority;  there  is  no  coordinated  end  produd. 

16.  There  is  a  Battle  Command  Migration  Plan  without  a  Network  Migration 
Plan;  impads  interoperability  requirements  process. 

17.  There  is  no  comprehensive  system-of-systems  description  avail  able  to  all 
developers  by  which  we  can  determine  interfaces;  we  cannot  ensure  our 
designs  achieve  interoperability. 

18.  There  is  a  lack  of  J  oint  Vision  (e.g.,  Network-Centric  Operations  and  Warfare 
Reference  Model  [NCOW-RM])  and  a  system-of-systems  organization  struc¬ 
ture;  leads  toward  a  stovepipe  development. 

19.  Some  systems  have  no  requirements  documents  (Tadical  Operations  Centers 
[TOCs]  and  Army  Airborne  Command  and  Control  System  [A2C2S])  or  the 
documentation  is  out  of  date;  there  is  no  clear  end  state  with  which  to  coordi¬ 
nate. 

20.  The  standards  for  knowledge,  skills,  and  attributes  of  capability  developers 
are  und  ear;  the  qual  ity  of  documents  may  suffer. 

21.  The  incentives  for  successful  Command/PM  do  not  support  sacrificial 
resource  distribution;  system-of-systems  interoperability  will  only  be  as  good 
as  its  weakest  proponent. 

22.  J  oint  system-of-systems  requirements  are  not  clear;  interoperability  is  not 
guaranteed  and  joint  testing  results  are  questionable. 

23.  There  is  a  lack  of  tradeoff  analysis  in  the  combat  development  process;  soft¬ 
ware  acquisition  is  not  efficient,  effedive,  and  timely. 
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4  Analysis 


The  foil  owing  subsections  describe  an  analysis  of  the  issues  based  on  the  system- 
of-systems  requirements,  system-of  systems  acquisition  management,  system-of- 
systems  construction,  and  joint  considerations.  Most  of  the  context  diagrams  (also 
known  as  interoperability  maps)  to  be  presented  here  were  developed  after  the 
workshop.  An  attempt  is  also  made  to  integrate  the  various  context  diagrams  into 
one  diagram. 


4.1  Approach 

The  analysis  of  attendee  issues  was  conducted  with  the  goal  of  developing  and 
understanding  the  context  diagrams.  (An  example  of  a  context  diagram  appeared 
in  Figure  1.)  The  steps  involved  in  the  analysis  included  an  identification  of  pat¬ 
terns  and  grouping  of  patterns  into  thematic  constructs. 

All  of  the  elements  of  a  context  diagram,  as  shown  in  Figure  1,  exhibit  the  same 
underlying  form:  They  can  be  represented  as  a  pattern  whose  structure  is  a  tuple 
<A1(  A2;  R>,  where  Ax  and  A2  represent  actors  and  R  describes  the  relation 
between  them.  For  example,  as  shown  in  Figure  2,  the  textual  statement  'The 
J  ROC  provides  requirements  to  the  PM  0"  could  be  represented  in  a  diagram¬ 
matic  form  or  in  terms  of  a  (textual)  pattern.  (The  relation  is  expressed  as  a  verb 
phrase— here  "provides  requirements";  when  parts  of  the  phrase  are  obvious,  a 
shorthand  can  be  used.) 


JROC 


provides  requirements 


Program 

Management 

Organization 


<JR0C,  PM0;  provides  requirements> 


Figure  2:  Representation  of  a  Textual  Statement 
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Patterns  may  express  the  negation  of  an  actor,  a  relation  among  actors,  or  both. 
When  a  textual  statement  is  described  in  terms  of  a  negation,  we  use  the  term 
anti  pattern.  I  n  terms  of  a  tuple,  the  general  form  for  an  anti  pattern  will  be 
denoted  <AV  A2;  R>with  the  underscores  denoting  the  negation  of  the  actor(s) 
and/or  their  relation,  as  appropriate.  For  example,  the  statement  'The  PMO  does 
not  perform  system  engineering"  would  be  represented  as  the  anti  pattern:  <PMO, 
system  engineering;  perform>.5  (Notice,  too  that  the  statement  'The  PMO  does 
not  perform  system  engi  neeri  ng"  actual  I  y  has  two  i  nterpretati  ons.  F  i  rst,  there  i  s 
an  understated  assertion  that  the  PMO  should  perform  system  engineering.  The 
second  interpretation  is  equivalent  to  the  assertion  that  the  PMO  does  not  per¬ 
form  system  engineering.) 

The  development  of  a  context  diagram  is  based  on  the  use  of  patterns  (and  anti¬ 
patterns).  The  patterns  are  developed  from  an  examination  of  the  textual  mate¬ 
rial.  An  example  of  this  process  is  shown  in  Appendix  E  on  page42. 

Having  collected  individual  patterns,  the  next  step  was  to  identify  central  themes 
on  which  the  patterns  could  be  aggregated.  No  formal  process  was  applied  to  iden¬ 
tify  such  themes.  However,  it  became  clear  that  the  issues  collected  could  be 
grouped  i  nto  the  fol  I  owi  ng  themes: 

■  system-of-systems  requirements 

■  system-of-systems  acquisition  management 

■  system-of-systems  construction 

■  joint  issues 

Each  of  these  themes  will  be  discussed  in  the  fol  I  owing  sections.  The  key  results  of 
the  analyses  will  be  integrated  and  presented  in  the  summary  of  this  section. 


4.2  System-of-Systems  Requirements 

Si  nee  the  primary  goal  of  the  workshop  was  to  elicit  and  understand  issues 
related  to  requirements  management  in  a  system-of-systems  context,  we  will 
begin  the  analysis  there.  The  issues  deemed  relevant  to  requirements  include 
(read  the character  as  the  word  therefore): 

■  System-of-systems  requirements  are  not  clearly  documented  or  configuration 


5  The  anti  pattern  <P  M  0,  system  engi  neeri  ng;  perform>  uses  a  shorthand  notati  on  for 
the  relation:  rather  than  as  the  more  formal  does  perform,  the  relation  is  presented  as 
perform. 
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controlled/managed;  they  cannot  be  further  allocated,  derived,  or  met  (Issue 
2). 

■  The  system-of-systems  user  combat  requirement  developer  is  not  clearly  char¬ 
tered;  cannot  derive  a  single  set  of  requirements  (I  ssue  3). 

■  There  is  no  method  for  validating  and  adjudicating  interoperability  require¬ 
ments  in  the  documentation  process;  interoperability  requirements  are  not 
defined  early  or  identified  as  a  common  development  goal  (I  ssue  6). 

■  There  is  no  ownership  of  system-of-systems  requirements;  there  is  no  follow¬ 
up  for  their  explanation  or  verification  (Issue  7). 

■  There  are  insufficient  resources  for  requirements  development  and  manage¬ 
ment;  shortcuts  are  taken  and  key  aspects  may  be  missed  (I  ssue  13). 

■  Some  systems  have  no  requi  rements  documents  (T OCs  and  A2C2S)  or  the  doc- 
umentation  is  out  of  date;  there  is  no  clear  end  state  with  which  to  coordinate 
(Issue  19). 

■  The  standards  for  knowledge,  skills,  and  attributes  of  capability  developers 
are  unclear;  the  quality  of  documents  may  suffer  (I  ssue  20). 

Prior  to  addressing  a  context  diagram  for  the  issues,  we  developed  with  the 

attendees  a  small  context  diagram  of  the  participants  in  the  requirements  pro¬ 
cess.  This  diagram  is  shown  in  Figure  3. 


G7 


G5 


interact  with  ^  Joint  Requirements 
Oversight  Council 
(JROC) 


^endorses  SOS  requirements 


TRADOC 

HQ 


TRADOC 

Program 

Integration 

Office 

(TPIO) 


TRADOC 

System 

Manager 

(TSM) 


Directorate  of  Combat  Developments  (DCDs) 


Figure  3:  High-Level  Context  Diagram  for  Requirements 


As  illustrated  in  Figure 3,  several  organizations— such  asaTPIO,TSM,  or  DCDs 
within  TRADOC— are  responsible  for  delivering  requirements  toTRADOC  HQ. 
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I  n  turn,  TRADOC  HQ  must  interact  with  various  Army  staff  organizations  (G3, 
G5,  and  G7)  that  endorse  requirements  for  an  SoS.  The  G3,  G5  and  G7  functions 
are  combined:  collectively,  they  form  strategy,  develop  the  force,  manage  the  func¬ 
tional  aspects  of  command  and  control,  and  establish  requirements  and  priorities 
for  the  employment  of  the  forces.  Following  this  interaction,  there  is  an  interac¬ 
tion  with  thej  ROC. 

The  attendees  emphasized  that  the  process  must  also  account  for  a  bottom-up 
perspective  because  the  details  of  the  user  requirements  for  individual  platforms 
are  only  available  at  the  "bottom."  Overall,  the  process  must  provide  for  an  inte¬ 
gration  of  interoperability  requirements  from  the  top  (e.g,  J  Cl  DS)  with  platform- 
focused  requirements  that  come  from  a  user  program.6 

A  context  diagram  of  the  identified  issues  appears  in  Figure  4.  The  complexity  of 
the  diagram  reflects  the  complexity  of  the  issues  identified.  (Recall  that  an  under¬ 
lined  term  represents  the  negation  of  actors  and/or  their  relations,  as  appropri¬ 
ate.) 

Some  points  regarding  this  figure  include 

■  A  number  of  issues  relate  to  staff:  I  n  particular,  it  was  observed  that  there 

-  were  insufficient  resources  for  requirements  development 

-  was  a  lack  of  standards  for  knowledge  and  skills  of  Capability  Developers 

-  was  no  charter  for  the  user  representati  ve  to  parti  ci  pate  i  n  the  process 

■  A  number  of  issues  relateto  the  activities  associated  with  requirements  man¬ 
agement: 

-  lack  of  methods  for  requirements  validation  and  conflict  adjudication 

-  documentation  of  requirements 

-  configuration  control  and  management 

■  I  n  addition,  the  following  are  worth  noting: 

-  Allocation  of  requirements  to  a  particular  system  is  difficult. 

-  The  qual ity  of  requi  rements  suffers. 

One  inference  that  follows  from  the  activities  related  to  requirements  manage¬ 
ment  is  that  the  requirements  management  process  is  not  performed  efficiently. 
This  inference  is  supported  by  several  of  the  issues  identified  by  the  attendees.7 


6  Notice  that  Figure  1  on  page4  indicates  that  J  ROC  provides  requirements  to  a  PMO. 
Those  requirements  are  presented  in  the  form  of  an  I  nitial  Capabilities  Document 
(ICD). 
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skill 


knowledge 


Figure  4:  Requirements  Context  Diagram 


4.3  System-of-Systems  Acquisition  Management 

Another  category  of  issues  relates  to  the  manner  in  which  a  system-of-systems 

acquisition  is  managed.  The  issues  relevant  to  this  category  include: 

■  System-of-systems  policy  and  mandates  are  without  incentives  and  enforce¬ 
ment;  does  not  ensure  change  from  stovepi  pe  to  SoS  (I  ssue  4). 

■  The  PPBES  is  not  synchronized  with  the  realities  of  system-of-systems  acqui¬ 
sition;  the  resources  required  are  not  in  the  right  place  at  the  right  time 
(event-driven  versus  time-driven  process  conflict).  (I  ssue  5) 

■  There  is  no  single  funding  line  for  systems  of  systems;  cannot  bring  personnel, 
resources,  and  priorities  together  sufficiently  to  develop  the  common  require¬ 
ments  (I  ssue  8). 

■  The  general  systems-of-systems  procedure  currently  in  pi  ace  does  not  produce 


7  The  attendees  did  not  identify  the  organization  that  would  be  responsible  for  providing 
the  charter  indicated  in  Figure  4— hence  the  "?".  In  addition  it  was  not  clear  what  orga¬ 
nization  "owned"  the  requirements  for  an  SoS,  although  a  number  of  possibilities  were 
offered  by  the  attendees. 
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effective  results;  there  is  a  need  for  a  process  that  is  comprehensive,  to  include 
timeframe,  management  structure,  definition  of  terms,  results,  and  responsi¬ 
bilities  (Issue  9). 

■  Systems-of-systems  lessons  learned  and  "good  idea"  insertion  are  not  incorpo¬ 
rated  and  managed;  the  benefit  of  experience  and  impact  of  requirement  creep 
are  not  considered  (Issue  14). 

■  DoD  maintains  multiple  systems  with  independent  users,  requirements,  and 
timelines  with  no  single  authority;  there  is  no  coordinated  end  product  (I  ssue 
15). 

■  There  is  a  Battle  Command  Migration  Plan  without  a  Network  Migration 
Plan;  impacts  interoperability  requirements  process  (I ssue  16). 

■  The  incentives  for  successful  Command/PM  do  not  support  sacrificial  resource 
distribution;  system-of-systems  interoperability  will  only  be  as  good  as  its 
weakest  proponent  (Issue 21). 

■  There  is  a  lack  of  tradeoff  analysis  in  the  combat  development  process;  soft¬ 
ware  acquisition  is  not  efficient,  effective,  and  timely  (Issue  23). 

A  context  diagram  for  the  acquisition  management  of  an  SoS  is  shown  in  Figure  5. 
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Figure  5:  System-of-Systems  Acquisition  Context  Diagram 


The  aspect  of  the  management  of  an  SoS  with  regard  to  funding  is  also  apparent 
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in  a  number  of  these  issues.  A  small,  very  simplified,  context  diagram  was  devel¬ 
oped  by  the  attendees,  and  it  appears  in  Figure  6.  The  attendees  did  not  identify 
the  relation  between  the  G3  and  G8  organizations;  hence  the "?". 


PEO 


submits 

budget 


G8 


G3 


authorizes  expenditures 


PPBES 


ASAALT 


Figure  6:  Context  Diagram  for  Funding 


A  key  actor  in  this  discussion  is  the  PPBES.8  The  purpose  of  the  PPBES  is  to  man¬ 
age  and  allocate  resources  to  the  DoD.  The  process  by  which  the  PPBES  operates 
is  divided  into  phases,  shown  in  Figure  7.  The  PPBES  operates  on  a  two-year 
cycle  with  multiple  cycles  running  concurrently.  The  activities  associated  with 
PPBES  are  both  generic  to  the  DoD  and  specific  to  the  Army,  as  shown  in  the  fig¬ 
ure.9 
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Supervise  and 
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Figure  7:  PPBES  Phases 


8  Recall  that  an  actor  can  be  anything  that  participates  in  the  requirements  management 
process.  Often,  an  actor  is  an  organization  or  an  individual,  but  this  need  not  always  be 
the  case. 

9  Some  background  on  the  PPBES  can  be  found  at  http://www.finance.army.mil 
/ppbes.htm. 
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An  issue  (Issue  5)  identified  during  the  workshop  was  that  the  PPBES  was  not 
synchronized  with  the  realities  of  system-of-systems  acquisition.  I  n  particular, 
the  resources  required  for  an  SoS  may  not  be  in  the  right  place  at  the  right  time. 
As  noted  by  the  attendees,  another  perspective  on  this  question  is  to  recognize  the 
PPBES  as  a  time-driven  process,  while  major  acquisition  decisions  are  event 
driven.  This  is  illustrated  in  Figure  8,  which  depicts  the  relation  between  the 
J  Cl  DS  process  and  the  acquisition  decisions  (from  Operation  ofthej  oint  Capabil¬ 
ities  I  ntegrati  on  and  Development  System  (J  CS  04]).  The  events  at  the  top  of  Fig¬ 
ure  8  are  associated  with  thej  ROC  process  and  those  in  the  center  are  associated 
with  program  acquisition;  the  bottom  of  thefigure  is  associated  with  the  PPBES 
process.  The  crux  of  the  i  ssue  rel  ates  to  the  synchroni  zati  on  of  events  of  a  vari  abl  e 
nature  (such  as  J  Cl  DS  and  acquisition  milestones)  with  events  having  a  fixed 
timeline  (those  associated  with  the  PPBES). 
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Figure  8:  JCIDS ,  Acquisition ,  and  PPBES  Events 


Moreover,  and  of  relevance  to  the  system-of-systems  context,  the  superposition  of 
many  program  events  associated  with  the  PPBES  and  their  harmonization  is  at 
the  heart  of  the  issue.  The  myriad  interactions  between  the  acquisition  system 
and  the  PPBES  is  another  reflection  of  the  bottom-up  (i.e.,  program-centric)  per¬ 
spective  on  how  the  process  is  executed.  On  the  other  hand,  a  strength  of  the 
PPBES  is  that  it  updates  information  on  all  programs  on  an  annual  basis,  regard¬ 
less  of  where  the  acquisition  programs  are  in  their  lifecycle. 

Issues  associated  with  funding  are  related  toother  timelines.  As  pointed  out  by 
the  attendees,  a  system  may  have  a  30-year  span,  the  development  for  that  sys- 
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tem  may  take  10  years,  and  the  typical  tour  of  a  program  manager  is  3  years.  To 
this  mix  are  added  funding  cycles  of  a  1-  or  2-year  duration.  A  depiction  of  the  var¬ 
ious  life-cycle  aspects  is  shown  in  Figure  9. 1  n  addition  to  the  comments  from  the 
attendees,  we  have  added  the  role  of  technologies  and  products  that  play  a  large 
part  of  the  devel opment  of  a  system— or  system  of  systems.  This  further  illus- 
trates  the  volatility  that  is  a  fundamental  part  of  the  acquisition  process. 
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Figure  9:  Relative  Life-Cycle  Durations 
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4.4  System-of-Systems  Construction 

The  term  system  construction  i  s  used  to  refer  to  those  acti  viti  es  that  rel  ate  to  the 

development  of  a  system.  Thus,  system-of-systems  construction  refers  to  the  con¬ 
struction  of  an  SoS.  The  foil  owing  issues  relate  to  this  topic. 

■  There  is  no  system  engineering  staff  above  the  PM  level  (e.g.,  Army  or  DoD); 
this  results  in  multiple  solutions  (stovepipes),  suboptimized  (at  a  lower  level) 
for  similar  probl ems— system-of-systems  hierarchy  is  missing  (Issue  1). 

■  The  Army  has  no  tools  (more  automated  than  Excel,  a  protocol  checker)  to 
adequately  model  interoperability;  must  wait  until  done  to  achieve  interopera¬ 
bility  by  trial  and  error  (Issue  11). 

■  There  is  a  lack  of  application  of  system  engineering  to  capability  development 
and  gap  analysis  (science  and  technology);  multiple  organizations  (uncoordi¬ 
nated)  working  on  multiple  solutions  to  solve  either  the  same  problem  or  simi- 
I  ar  probl  ems  (I  ssue  12). 

■  There  is  no  comprehensive  system-of-systems  description  avail  able  to  all 
developers  by  which  we  can  determine  interfaces;  we  cannot  ensure  our 
designs  achieve  interoperability  (Issue  17). 
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The  highest  rated  issue  identified  by  the  attendees  was  There  is  no  system  engi¬ 
neering  staff  above  the  PM  level  (Army  or  DoD);  this  results  in  multi  pie  solutions 
(stovepipes),  suboptimized  (at  lower  level)  for  similar  problems—  system-of -systems 
hierarchy  is  missing.  A  context  diagram  showing  the  relation  between  actors 
engaged  in  the  system  engineering  process  is  shown  in  Figure  10.  This  context 
diagram,  I  ike  others  presented  previously,  was  based  on  an  analysis  of  the  issues 
identified.  I  n  this  case,  however,  we  have  inferred  the  absence  of  an  SoS  System 
Engineering  Organization,  shown  at  the  top  of  the  figure.  This  inference  was 
based  on  the  identified  lack  of  a  system  engineering  staff  above  the  PMO  level. 
The  lack  of  staff  implies  the  lack  of  an  associated  organization. 
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Figure  10:  System-of-Systems  Construction  Context  Diagram 


Figure  10  also  shows  a  thread  related  to  the  use  of  models  to  assess  capabilities, 
part  of  an  expected  system  engineering  approach.  I  n  fact,  the  analysis  of  alterna¬ 
tives  (AOA)  was  mentioned  as  not  being  done  in  the  context  of  an  SoS. 
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It  is  relevant  to  incorporate  a  discussion  of  the  Army  regulation  that  applies  to 
this  point.  The  foil  owing  is  from  Army  Acquisition  Policy,  regarding  aPM’s 
responsibilities: 

The  systems  engineering  program  will  include  full  integration  of  the  programs  of 
other  systems  that  have  an  interoperability  requirement  with  this  system.  This 
includes  both  technical/operational  synchronization  and  schedule  harmonization 
across  programs  of  interoperational  systems.  . .  .  Systems  engineering  must  be 
done  from  a  system-of-systems  perspective  in  accordance  with  the  Software 
Blocking  Policy  and  its  implemented  processes  [DoA  03,  p.  40]. 

One  infers  from  this  statement  that  system  engineering  must  be  done  in  accor¬ 
dance  with  the  software  blocking  policy  [DoA  01].  Yet,  the  phrase  "system  engi- 
neeri  ng"  does  not  appear  i  n  the  software  bl  ocki  ng  pol  i  cy.  There  are  cl  ear 
implications  from  this  approach.  I  n  particular,  each  program  manager  is  responsi¬ 
ble  for  system  engineering  for  their  program,  developed  in  the  larger  system-of- 
systems  perspective.  It  is  not  clear,  however,  how  conflicts  are  adjudicated  in  the 
process  and  who  is  responsible  for  the  system-of-systems  view  as  a  whole. 


4.5  Joint  Considerations 

There  is  a  clear  intent  to  move  from  a  requirements-based  process  to  one  that  is 
based  on  capabilities.  This  transformation  is  described  in  they  oint  Capabilities 
and  I  integration  Development  System  (I  CIDS)  Process  and  related  documents 
[J  CS  01,  J  CS  03,  J  CS  04,  and  J  CS  05], 

Although  it  was  not  the  intent  of  this  workshop  to  focus  on  issues  related  tojoint 
requirements  management,  several  issues  were  identified,  including: 

■  The  J  Cl  DS  process  has  no  path  that  leads  to  a  view  (architecture)  that  can  be 
used  for  a  statement  of  specification  for  a  material  developer  or  test  criteria  by 
the  combat  devel oper;  there  i s  no  di red:  link  from  requi rements  to  end  product 
(Issue  10). 

■  There  is  a  lack  of  J  oint  Vision  (e.g.,  NCOW-RM)  and  a  system-of-systems  orga¬ 
nization  structure;  leads  toward  a  stovepipe  development  (Issue  18). 

■  J  oint  system-of-systems  requirements  are  not  clear;  interoperability  is  not 
guaranteed  and  joint  testing  results  are  questionable  (I  ssue  22). 

A  context  diagram  for  the  issues  related  to  the  joint  environment  appears  in  Fig¬ 
ure  11.  Details  of  the  approach  used  to  construct  this  context  diagram  may  be 
found  in  Appendix  E. 
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Figure  1 1 :  Context  Diagram  for  Joint  Issues 

I  n  some  sense,  the  issues  identified  at  the  workshop  for  the  joint  environment  are 
tantamount  to  a  scaling  of  the  Army-centric  issues.  For  example,  the  identified 
lack  of  a  system  engineering  process  for  an  SoS  within  the  Army  will  have  impli- 
cati  ons  for  the  success  of  system  engi  neer i  ng  i  n  a  j  oi  nt  system-of-systems  envi  ron- 
ment.  I  n  addition,  it  was  pointed  out  that  there  is  a  merger  of  top-down 
capabilities  with  a  bottom-up  perspective,  based  on  requirements.  Such  a  perspec¬ 
tive  can  lead  to  difficulties,  some  of  which  appeared  even  in  the  context  of  Army 
Aviation  issues  identified  in  this  workshop.  Note  also  that  the  issue  of  a  lack  of 
clarity  in  specification  of  joint  requirements  will  have  an  impact  on  the  Army's 
abi  I  ity  to  i  mpl  ement  those  requi  rements. 

Because  the  focus  of  the  workshop  was  on  Army  Aviation,  rather  than  on  joint 
considerations,  we  will  not  further  address  the  joint  issues.  However,  inferences 
from  the  precedi  ng  di  scussi  on  may  wel  I  apply  to  the  j  oi  nt  scope.  The  i  ntegrati  on  of 
the  J  Cl  DS  process  with  a  service-specific  process  for  some  domain,  such  as 
requirements  management,  may  be  worth  further  consideration. 
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4.6  Summary  of  Analyses 

Although  the  workshop  was  oriented  toward  a  system-of-systems  perspective,  it  is 
not  possi  bl  e  to  el  i  mi  nate  consi  derati  ons  of  a  P  M  O.  I  n  fact,  such  poi  nts  were  fre- 
quently  raised  in  the  discussion  of  the  issues.  Thus,  we  begin  by  considering  a 
high-level  context  diagram  shown  in  Figure  12. 

SoS 

Acquisition 

Management 

includes 

I 


SoS 

Requirements  SoS 

Management  System 


Note:  Shaded  line  denotes  the  boundary  between  a  system-of-systems  perspective  and  a  PMO  perspective. 

Figure  12:  Themes  for  Integrated  Issues 

Consideration  of  the  actors  and  their  relations  as  shown  in  Figure  12  depicts  two 
perspectives: 

1.  There  is  a  program-centric  view,  shown  at  the  bottom  of  the  figure,  where  the 
programs  apply  a  traditional  system  engineering  approach  to  the  develop¬ 
ment  (and  maintenance,  etc.)  of  their  systems.  This  part  of  the  figure  could 
have  been  elaborated  more  to  show  details  of  that  approach. 

2.  There  is  a  system-of-systems  view,  shown  at  the  top  of  the  figure,  that  can  be 
interpreted  as  the  application  of  a  traditional  system  engineering  approach  to 
an  SoS. 

We  now  expand  the  view  of  Figure  12  to  account  for  the  issues  identified  by  the 
attendees.  Only  the  highest  priority  issues  will  be  considered.  Upon  doing  so  we 
have  the  context  map  shown  in  Figure  13. 
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The  view  shown  in  Figure  13  reflects  the  concerns  of  the  attendees  and  the  issues 
they  raised.  (The  issue  numbers  shown  in  circles  refer  to  the  list  presented  on 
page  8  and  mentioned  in  this  section.)  Recall,  for  example,  that  several  of  the 
actors  shown  in  this  figure  were  inferred  in  order  to  frame  the  discussion.  I  n  fact, 
several  such  actors  do  not  exist  (e.g.,  the  SoS  Acquisition  Management  organiza¬ 
tion). 


Note:  Shaded  line  denotes  the  boundary  between  a  system-of-system  perspective  and  a  PMO  perspective. 
Numbers  in  circles  denote  issues. 


Figure  13:  Summary  Context  Map 


Thus,  whilethere  is  an  attempt  to  apply  a  traditional  system  engineering  view  to 
the  SoS  (i.e.,  "after  all,  a  system  of  systems  is  just  another  system"),  there  are  con¬ 
flicts  in  the  way  that  this  view  is  manifest. 

Several  points  stand  out,  as  noted  by  the  attendees: 
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■  There  is  no  system  engineering  above  the  program  level. 

■  Requirements  are  not  managed  in  the  context  of  the  SoS. 

■  System-of-system  policies  and  processes  are  not  sufficiently  comprehensive 
and  are  without  mandates  and  incentives. 

■  Thereis  no  singlefunding  linefor  an  SoS. 

On  the  one  hand,  there  is  the  desire  to  treat  an  SoS  as  another  system.  But  on  the 
other  hand,  there  are  conflicts  (funding,  management,  and  system  engineering, 
for  example)  that  prevent  such  an  approach  from  succeeding. 
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5  Relation  to  Future  Force  Workshop 


TheSEI  conducted  a  workshop  with  individuals  connected  with  the  F  uture  Force; 
the  results  of  that  session  are  presented  in  Exploring  Programmatic  Interopera¬ 
bility:  Army  F  uture  Force  Workshop  [Smith  05].  The  attendees  of  the  F  uture  Force 
Workshop  came  from  various  Army  organizations  and  reflected  a  significant 
breadth  and  depth  of  acquisition  experience,  including  individuals  from  Army 
headquarters;  staff  elements;  J  oint  and  Army  acquisition  organizations;  opera¬ 
tional  test,  research,  and  development  areas;  and  training  and  doctrine  groups. 

I  n  the  foil  owing  sections,  we  examine  the  issues  identified  by  those  individuals  at 
that  workshop.  (We  wi  1 1  al  so  refer  at  ti  mes  to  the  system-of-systems  requi  rements 
management  workshop  as  the  current  or  present  workshop.) 


5.1  Organizational  Concerns 

The  highest  priority  issue  from  the  F  uture  Force  Workshop  was  the  foil  owing:  The 
Army  is  not  organized  to  develop  a  system  of  systems.  There  is  a  lack  of  under¬ 
standing  of  requirements,  money  allocation,  interaction,  and  testing. 

This  issue  results  from  the  fact  that  while  the  Army  fields  operational  capability 
as  integrated  units  of  personnel  and  equipment  in  a  defined  structural  relation¬ 
ship,  it  procures  systems  individually,  in  response  to  separate  operational  require¬ 
ments,  appropriations,  or  the  like.  As  a  result,  the  organization  of  the  acquisition 
system  does  not  inherently  encourage  the  tradeoffs,  across  systems  within  the 
SoS,  necessary  to  maximize  operational  effectiveness  of  the  Army  as  a  whole. 

Many  of  the  results  from  the  current  workshop  are  directly  related  to  the  issue  of 
organizational  factors  in  the  development  of  an  SoS.  For  example,  attendees  iden¬ 
tified  issues  related  to  a  lack  of 

■  system  engi  neeri  ng  staff  above  the  P  M  I  evel 

■  understandi  ng  of  system-of-systems  requi  rements 

■  a  comprehensi  ve  process  for  an  SoS  to  i  nd  ude  ti  me  frame,  management  struc¬ 
tures,  and  responsibilities 

In  the  Future  Force  Workshop,  participants  also  placed  concerns  related  to 
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requirements  under  this  topic.  I  n  the  present  workshop,  these  issues  were 
explored  in  greater  detail  and  confirmed  the  results  obtained  in  the  Future  Force 
Workshop. 


5.2  Procurement  vs.  Development  Life  Cycle 

This  was  the  second  highest  priority  issue  from  the  Future  Force  Workshop:  The 
procurement  versus  development  lifecycle  models  cause  interoperability  problems 
when  functions  are  implemented. 

This  issue  arises  when  different  systems  that  have  to  be  interoperable  are  pro¬ 
cured  separately.  I  nteroperability  is  commonly  defined  by  sets  of  standards  and 
interfaces,  with  systems  required  to  implement  these  in  some  common  fashion. 
Frequently,  the  organization  responsible  for  procuring  system  A  chooses  for  pro¬ 
grammatic  reasons  (e.g.,  funding  profile)  to  implement  pieces  of  the  required  stan¬ 
dards  in  a  different  way  than  that  selected  by  the  acquiring  organization  for 
system  B  (for  equally  sound  programmatic  reasons). 

The  differences  in  implementation  approach  can  result  in  the  two  systems  being 
unable  to  interoperate  until  both  have  implemented  all  portions  of  the  specified 
standards.  Si  nee  the  procurement  life  cycles  for  both  systems  are  driven  by  their 
individual  requirements  and  funding  lines,  interoperability  is  often  delayed  for 
unacceptably  long  periods  of  time. 

Coupling  the  procurement  and  development  life-cycle  models  raises  issues  per¬ 
taining  to  funding.  In  the  current  workshop,  participants  identified  several  con¬ 
cerns  rel  ated  to  the  I  ack  of 

■  synchronization  between  the  PPBES  and  the  realities  of  the  acquisition  pro¬ 
cess 

■  a  single  funding  line  for  an  SoS 

■  resources  for  requi  rements  devel  opment  and  management 

Si  nee  procurement  I  i fe  cyd  es  are  associ  ated  with  i  ndi  vi  dual  systems  (havi  ng  thei  r 
own  requirements  and  funding  lines),  synchronization  of  multiple  system  acquisi¬ 
tions  only  makes  the  problem  more  difficult.  And  this  problem  is  further  exacer¬ 
bated  by  the  I  ack  of  a  system  engi  neeri  ng  functi  on  at  the  system-of-systems  I  evel . 


5.3  Migration  Plans 

This  was  the  third  highest  priority  issue  from  the  F  uture  Force  Workshop:  A 
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migration  plan  must  be  at  the  appropri  ate  hi gher  I &/el ,  not  based  on  a  bottom-up 
perspecti  ve.  N  etwork—not  the  radi os,  fi el di ng. 


This  issue  reflects  the  "disconnect"  between  the  present  approach  to  migration 
planning  (i.e.,  system  by  system)  and  the  need  to  plan  migration  at  the  force  capa¬ 
bility  level  (e.g.,  Future  Force).  Unresolved,  this  issue  can  lead  to  a  decrease  in 
interoperability  if  an  upgraded  system  does  not  provide  an  exact  "form-fit-func¬ 
tion"  replacement  for  its  predecessor— as  is  often  the  case.  One  example  cited  by 
the  participants  involved  a  new  system  being  fielded  to  operational  units  that 
were  required  to  i nteroperate:  as  each  unit  received  the  new  system— in  accor¬ 
dance  with  the  fielding  plan  for  the  new  system— it  had  the  old  system  removed. 
Unfortunately,  the  new  system  wasn't  fully  backward-compatible  with  the  old  sys¬ 
tem,  and  the  system  fielding  plan  didn't  reflect  the  operational  reality  that  the 
units  had  to  deploy  and  work  together.  U  ntil  all  the  units  received  and  installed 
the  new  system,  then,  there  was  a  net  loss  of  interoperability  and,  as  a  result, 
operational  effectiveness. 

I  n  the  present  workshop,  the  topic  of  a  migration  plan  came  up  but  was  of  rela¬ 
tively  lesser  importance.  In  particular,  it  was  pointed  out  therethata  Battle  Com¬ 
mand  Migration  Plan  without  a  Network  Migration  Plan  can  impact  the 
interoperability  requirements  process.  This  view  represents  a  different,  though 
related,  perspective  from  that  raised  in  the  Future  Force  Workshop. 

Both  groups'  comments  point  to  the  need  for  a  discussion  of  requirements  for  the 
migration  plan.  Further,  such  discussion  must  be  at  the  higher  level— not  at  a 
system  or  program  level  because  that  perspective  leads  to  a  locally  optimized 
approach  without  consideration  of  the  system-of-systems  perspective. 


5.4  Measuring  Operational  Benefit 

The  fourth  highest  priority  issue  from  the  F  uture  Force  Workshop  was:  There  is  a 
need  for  a  process  for  measuring  operational  benefit  of  proposed  interoperability 
solutions  (eg.,  cost-benefit  analysis). 

Because  so  much  of  the  focus  on  justifying  the  upgrades  and  migration  of  new 
capability  is  driven  by  the  individual  system's  cost-benefit  analysis,  there  is  no 
agreed-upon  mechanism  for  performing  such  analyses  at  the  system-of-systems 
level.  Or,  where  such  analyses  are  performed,  they  are  frequently  driven  by  the 
procurement,  fielding,  and  sustainment  costs  of  the  proposed  upgrade,  not  of  the 
original  system.  This  approach  generally  results  in  an  AOA  that  reflects  a  locally 
optimized  solution  for  an  individual  program  or  system  rather  than  a  measure  of 


CMU/SEI-2006-TN-015 


27 


the  operational  benefits  of  the  proposed  upgrades  in  the  larger  perspective. 


Two  items  from  this  workshop  are  related  to  operational  benefit. 

1.  There  was  a  perceived  lack  of  tradeoff  analysis  in  the  combat  developer  pro¬ 
cess,  resulting  in  inefficient,  ineffective,  and  untimely  software  acquisition. 
Note  also  the  close  relation  between  measuring  operational  benefit  and 
migration  planning.  In  particular,  migration  of  system  capabilities  is  driven 
by  an  individual  system;  however,  this  may  not  be  the  same  perspective  when 
one  considers  operational  benefit  at  the  system-of-systems  level . 

2.  A  second  point  made  was  that  there  was  a  lack  of  analysis  of  alternatives  per¬ 
formed  in  the  context  of  an  SoS.  This  point  was  noted  in  connection  with  Fig¬ 
ure  10  on  page  19. 


5.5  Summary 

The  most  important  overall  result  from  the  Future  Force  Workshop  was  a  recogni¬ 
tion  that  better  understanding  is  needed  of  the  relationship  between  the  Army 
Campaign  Plan  for  the  Future  Force  vision  and  the  expected  approaches  to 
develop  an  acquisition  strategy  to  achieve  that  vision.  The  results  from  the 
present  workshop,  stressing  the  role  of  requirements  management  in  this  larger 
system-of-systems  context,  are  di redly  related  to  results  from  the  F uture  Force 
Workshop. 
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6  Summary 


This  report  summarizes  the  results  and  analyses  of  a  workshop  dealing  with 
requirements  issues  in  a  system-of-systems  context.  Senior  staff  associated  with 
the  Army  PEO  Aviation  and  TRADOC  Directorate  of  Combat  Developers 
attended  the  workshop. 

Onethemethat  clearly  emerges  from  this  work  is  the  foil  owing:  Thereis  a  conflict 
in  the  approach  to  a  system  of  systems  between  top-down,  policy  driven  and  bot- 
tom-up,  program-centri c approaches.  This  clash  is  perhaps  expected:  the  acquisi¬ 
tion  community  is  naturally  focused  on  a  particular  system,  and  there  are 
mandates  about  how  funding  is  allocated  in  this  manner.  An  SoS  requires  a  larger 
perspective,  however.  Based  on  this  workshop,  the  clash  was  evident  from  the  per¬ 
spective  of  requirements  management  in  a  system-of-systems  context. 

From  an  analysis  of  issues  presented  at  this  workshop,  there  are  a  number  of  pos¬ 
sible  fol  I  ow-on  efforts.  Among  them,  we  would  mention: 

■  exploring  the  role  of  the  Army  software  blocking  policy,  as  it  relates  to  achiev¬ 
ing  interoperability  among  requirements 

■  investigating  the  role  of  thej  Cl  DS  process  and  its  relation  to  requirements 
management  implemented  by  a  particular  service-specific  system(s)  in  the 
context  of  an  SoS 

■  investigating  the  role  of  the  PPBES  as  it  relates  to  the  acquisition  of  an  SoS, 
as  compared  to  the  acquisition  of  individual  systems 

■  investigating  the  possible  barriers  imposed  by  the  current  legal  framework 
(laws,  regulations,  policies,  etc.)  that  impact  acquisition  of  an  SoS 

■  understanding  the  differences  between  an  SoS  and  an  FoS,  as  per  the  cur¬ 
rently  specified  Army  acquisition  process  (recall  the  discussion  on  Section  1) 

■  i  nvesti  gati  ng  the  approach  of  usi  ng  patterns  (and  anti  patterns)  as  a  means  to 
make  and  present  inferences  regarding  user-collected  information  from  work¬ 
shops  such  as  this  one 
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There  is  work  ongoing  in  some  of  these  topics  at  the  SE I .  There  is  also  a  need  to 
integrate  the  results  of  this  workshop  with  related  efforts  to  gain  a  broader 
understanding  of  interoperability  aspects  of  system-of-systems  management,  con¬ 
struction,  and  operation.  This  workshop  is  a  step  along  the  way  to  developing,  and 
understanding,  the  larger  picture. 
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A  Family  of  Systems  and  System  of 
Systems 


I  n  the  introduction,  a  definition  of  the  term  system  of  systems  was  presented.  A 
related  term  is  a  family  of  systems.  Our  purpose  in  this  Appendix  is  to  examine 
the  manner  in  which  these  terms  are  defined.  As  background,  both  terms 
appeared  in  connection  with  the  Requirements  Generation  System.  In  that  docu¬ 
ment,  those  terms  are  defi  ned  as  fol  I  ows: 

system  of  systems:  A  set  or  arrangement  of  systems  that  are  related  or  connected 
to  provide  a  given  capability.  The  loss  of  any  part  of  the  system  will  degrade  the 
performance  or  capabilities  of  the  whole. 

family  of  systems:  A  set  or  arrangement  of  independent  systems  that  can  be 
arranged  or  interconnected  in  various  ways  to  provide  different  capabilities.  The 
mix  of  systems  can  be  tailored  to  provide  desired  capabilities  dependent  on  the 
situation  [JCS  01] 

The  Army  adopted  these  definitions  with  some  further  explanatory  text.  However, 
it  is  interesting  to  notethat  the  Army  Software  Blocking  Policy  (published  in 
2001)  contains  the  fol  I  owing: 

system  of  systems:  The  collection  of  systems  that  share/exchange  information 
which  interact  synergistically.  Other  documents  outside  of  this  policy  may  refer  to 
the  SoS  as  a  'Family  of  Systems'  [DoA  01] 

Later,  th  e  Army  Acquisition  Policy,10  published  in  2003,  includes  the  fol  I  owing 
definitions: 

system  of  systems:  A  set  or  arrangement  of  interdependent  systems  that  are 
related  or  connected  to  provide  a  given  capability.  The  loss  of  any  part  of  the  sys¬ 
tem  will  degrade  the  performance  or  capabilities  of  the  whole.  An  example  of  a 
SoS  could  be  interdependent  information  systems.  While  individual  systems 
within  the  SoS  may  be  developed  to  satisfy  the  peculiar  needs  of  a  given  user 

10  The  Army  Acquisition  Policy  is  principally  focused  on  a  system  of  systems  and  only 
mentions  a  family  of  systems.  The  references  to  a  system  of  systems  and  a  family  of 
systems  number  21  and  4,  respectively.  Apart  from  the  definition  of  a  family  of  sys¬ 
tems,  the  only  substantive  comment  is  that  a  Capstone  Requirements  Document 
applies  to  a  family  of  systems. 
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group,  the  information  they  share  is  so  important  that  the  loss  of  a  single  system 
may  deprive  other  systems  of  the  data  needed  to  achieve  even  minimal  capabili¬ 
ties. 

family  of  systems:  A  set  or  arrangement  of  interdependent  systems  that  can  be 
arranged  or  interconnected  in  various  ways  to  provide  different  capabilities.  The 
mix  of  systems  can  be  tailored  to  provide  desired  capabilities,  dependent  on  the 
situation.  An  example  of  a  family  of  systems  is  a  unit  of  action  that  included  armor, 
infantry,  artillery,  and  combat  support  systems  [DoA  03]. 

Further  explanation  regarding  a  family  of  systems  may  be  found  in  the  Operati  on 
ofthej  oint  Capabilities  and  Integration  Development  System,  published  in  2004, 
where  the  foil  owing  example  is  added  to  the  definition: 

An  example  of  a  FoS  would  be  an  anti-submarine  warfare  FoS  consisting  of  sub¬ 
marines,  surface  ships,  aircraft,  static  and  mobile  sensor  systems  and  additional 
systems.  Although  these  systems  can  independently  provide  militarily  useful 
capabilities,  in  collaboration  they  can  more  fully  satisfy  a  more  complex  and  chal¬ 
lenging  capability:  to  detect,  localize,  track  and  engage  submarines  [JCS  04], 

Still  more  discussion  of  a  both  terms  may  be  found  in  they  oint  Capabilities  and 
Integration  Development  System,  published  in  2005: 

system  of  systems  (SoS):  A  set  or  arrangement  of  interdependent  systems  that 
are  related  or  connected  to  provide  a  given  capability.  The  loss  of  any  part  of  the 
system  will  significantly  degrade  the  performance  or  capabilities  of  the  whole.  The 
development  of  a[n]  SoS  solution  will  involve  trade  space  between  the  systems  as 
well  as  within  an  individual  system  performance.  An  example  of  a[n]  SoS  would  be 
a  combat  aircraft.  While  the  aircraft  may  be  developed  as  a  single  system,  it  could 
incorporate  subsystems  developed  for  other  aircraft.  For  example,  the  radar  from 
an  existing  aircraft  may  be  incorporated  into  the  one  being  developed  rather  than 
developing  a  new  radar.  The  SoS  in  this  case  would  be  the  airframe,  engines, 
radar,  avionics,  etc.  that  make  up  the  entire  combat  aircraft  capability. 

family  of  systems  (FoS):  A  set  of  systems  that  provide  similar  capabilities  through 
different  approaches  to  achieve  similar  or  complimentary  effects.  For  instance,  the 
warfighter  may  need  the  capability  to  track  moving  targets.  The  FoS  that  provides 
this  capability  could  include  unmanned  or  manned  aerial  vehicles  with  appropriate 
sensors,  a  space-based  sensor  platform  or  a  special  operations  capability.  Each 
can  provide  the  ability  to  track  moving  targets,  but  with  differing  characteristics  of 
persistence,  accuracy,  timeliness,  etc  [JCS  05]. 

It  is  not  our  intent  to  engage  in  a  detailed  discussion  of  the  differences  between 
these  concepts.  As  noted  on  page  1,  the  attendees  did  not  distinguish  between  an 
SoS  and  an  FoS  during  the  workshop. 
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However,  one  perspective  on  the  difference  between  an  SoS  and  an  FoS  can  be 
addressed  in  terms  of  the  coupling  by  the  individual  components  that  form  the 
larger  unit.  We  would  suggest,  for  example,  there  is  a  tighter  coupling  among 
components  of  an  SoS  than  an  FoS.  One  could  also  argue  that  an  FoS  is  not  a  sys¬ 
tem,  but  rather  a  collection  of  systems  built  to  a  common  set  of  rules  and  stan¬ 
dards  that  can  be  composed  to  form  an  SoS. 

A  point  here  is  that  to  the  extent  that  there  may  be  differences  between  an  SoS 
and  an  FoS,  there  can  be  implications  for  the  requirements  process.  This  point  is 
discussed  further  in  Appendix  B. 


CMU/SEI-2006-TN-015 


33 


B  Requirements  for  Systems  of  Systems: 
An  Alternative  View 


The  definition  provided  on  page  1  essentially  labels  an  SoS  as  a  large-scale  entity 
wherein  each  of  its  components  is  a  system.  Presumably  the  system  and  the  SoS 
can  be  developed  using  traditional  system  engineering  techniques.  However,  such 
a  definition  leads  the  reader  into  thinking  that  an  SoS  is  really  just  a  larger  scale 
object  than  a  system.  An  alternative  view  provided  by  Maier11,  is  that  an  SoS  is  of 
a  different  nature.  Maier  states  that  an  SoS  has  the  foil  owing  characteristics: 

■  operational  independence  of  the  systems 

Each  of  the  individual  systems  within  an  SoS  has  a  "life  of  its  own"  and  can 
function  acceptably  and  provide  useful  service  without  necessarily  interacting 
with  other  systems. 

■  managerial  independence  of  the  systems 

The  individual  systems  within  an  SoS  are  under  different  authorities.  Within 
the  DoD  context,  these  could  be  significantly  different  authorities  in  that  dif¬ 
ferent  services  will  own  different  systems  in  the  context  of  an  SoS. 

■  evol  uti  onary  devet  opment 

The  different  systems  within  the  SoS  are  developed  and  upgraded  on  uncoor¬ 
dinated  schedules.  While  policies  such  as  the  software  blocking  policy  can 
coordinate  the  schedules  for  a  number  of  systems  within  an  SoS,  it  is  unlikely 
that  such  a  policy  can  scale  to  a  size  of  the  Global  I  nformation  Grid  (Gl  G). 

■  emergent  behavior 

The  behavior  of  the  SoS  as  a  whole  is  not  embodied  in  any  one  of  the  systems 
withi  n  it.  E  mergent  behavi  or  i  s  a  di  red  consequence  of  havi  ng  the  systems 
interad;  the  difficulty  is  ensuring  that  the  emergent  behavior  is  desirable. 

■  geographic  distribution 

Simply  put,  the  systems  within  the  SoS  are  not  all  co-located.  While  it  is 
highly  likely  that  any  significant  fielded  SoS  will  have thi s  charaderi Stic,  it  is 
by  no  means  obvious  that  it  is  a  necessary  charaderi  Stic. 


11  A  reference  to  Maier's  work,  as  discussed  here,  can  be  found  at 
htt  p  ://www.  i  nf  oed .  com/O  pen/P  A  P  E  R  S/systems,  ht  m. 
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I  n  a  more  recent  presentation,  Maier  no  longer  discusses  the  emergent  behavior 
characteristic  and  suggests  that  there  are  counter  examples  to  the  geographic  dis¬ 
tribution  aspect.  Hence,  geographic  distribution  is  no  longer  considered  a  funda¬ 
mental  characteristic. 

Notice  that  the  definition  of  an  SoS,  provided  in  the  I  ntroduction  and  elaborated 
further  in  Appendix  A,  is  not  described  in  terms  of  the  characteristics  identified 
by  Maier.  One  might  infer,  for  example,  that  the  approach  to  an  SoS  in  terms  of 
interdependent  systems  would  disagree  with  the  Maier  characteristic  of  opera¬ 
tional  independence. 

However,  our  intent  hereis  not  to  examine  the  current  definitions  in  light  of  the 
Maier  characteristics.  We  intend  to  consider,  based  on  the  three  key  characteris¬ 
tics  (namely,  operational  independence,  managerial  independence,  and  evolution¬ 
ary  development),  what  it  means  to  perform  requirements  engineering  in  the 
context  of  an  SoS. 

It  is  clear  that  each  of  the  individual  systems  will  have  a  definition  of  the  require¬ 
ments  for  its  own  independent  operational  capabilities.  However,  neither  the  ori - 
gi  n  of  requi  rements  for  the  emergent  behavior  nor  the  way  those  requi  rements  are 
levied  on  individual  systems  is  obvious.  Emergent  behavior,  as  we  stated,  is  not  a 
result  of  the  operation  of  any  one  system;  rather,  it  is  the  result  of  the  interactions 
between  multiple  systems.  No  single  system  can  be  tested  to  see  if  it  exhibits  the 
emergent  behavi  or.  1 1  i  s  only  i  n  the  context  of  an  SoS  that  a  test  can  be  performed. 
While  they  can  demonstrate  the  presence  of  desirable  emergent  behavior,  such 
tests  are  unlikely  to  demonstrate  the  absence  of  undesirable  emergent  behavior. 

I  n  the  extreme  case,  where  systems  are  composed  dynamically,  no  a  priori  test  is 
possible  when  the  SoS  is  assembled— since,  at  that  time,  no  one  can  know  which 
systems  will  be  called  upon  to  satisfy  any  given  mission  thread. 

Within  an  SoS,  each  individual  system  will  likely  have  a  different  owner,  and 
those  owners  will  report  up  through  independent  management  chains!  Poten¬ 
tially,  in  a  large  SoS,  those  chains  may  report  in  different  services,  departments, 
or  even  coalition  partners.  It  would  be  nice  if  some  group  were  responsible  for  the 
development  of  requirements  of  the  SoS,  including  its  emergent  behavior.  Yet, 
since  no  one  group  owns  the  SoS,  there  is  no  obvious  group  that  owns  its  require¬ 
ments.12  And,  again,  in  the  extreme  case,  those  requirements  may  only  be  known 
when  a  particular  mission  requires  functionality  from  a  particular  set  of  systems 
within  the  SoS. 

Finally,  if  we  consider  the  issue  of  evolutionary  development,  we  again  see  a  prob¬ 
lem  for  requirements.  Since  the  various  systems  within  the  SoS  will  change  at 


CMU/SEI-2006-TN-015 


35 


their  own  rates  (the  software  blocking  policy  notwithstanding),  the  capabilities  of 
the  individual  systems  will  also  change  independently.  I  ndeed,  in  the  more  likely 
case,  the  systems  that  compose  the  SoS  wi  1 1  change  over  ti  me  as  systems  come 
and  go.  Thus,  the  capabilities  of  the  SoS  can  only  ever  be  defined  in  terms  of  what 
it  can  do  at  any  given  instant,  and  those  capabilities  are  expected  to  evolve  over 
time.  If  the  capabilities  are  unknowable  at  assembly  time,  it  is  also  unknown, 
then,  which  requirements  can  or  cannot  be  satisfied. 

N  ow,  the  above  arguments  are  not  an  attempt  to  di  smi  ss  requi  rements  for  an  SoS 
as  being  impossible  to  develop  or  maintain.  Rather,  they  are  the  basis  for  suggest- 
i  ng  that  a  new  approach  to  system-of-system  requi  rements  wi  1 1  be  necessary.  T ra- 
ditional  system  engineering  techniques  do  not  appear  to  apply  to  the  SoS;  they 
are  necessary,  but  not  sufficient.  Unfortunately,  it  is  not  immediately  obvious  how 
the  problem  can  or  should  be  solved. 


12  I  n  addition,  it  would  be  nice  if  there  were  a  central  group  responsible  for  the  identifica¬ 
tion  and  resolution  of  conflicts  among  requirements  that  may  exist.  However,  other 
approaches  to  conflict  identification  and  resolution  are  also  possible.  For  example,  it 
may  be  the  responsibility  of  the  individual  systems  to  identify  and  resolve  conflicts 
based  upon  peer  interactions. 
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C  Requirements  Management 


Requirements  management  is  a  key  process  that  is  performed  as  part  of  the 
acquisition  of  a  system.  The  process  is  discussed  in  a  number  of  sources,  such  as 
the  SEI  CM  Ml®13  framework.  A  typical  list  of  activities  associated  with  require¬ 
ments  management  includes  the  foil  owing  (from  CM  Ml )  [Chrissis  03]: 

■  develop  customer  requirements 

-  collect  stakeholder  needs 

-  elicit  needs 

-  develop  the  customer  requi  rements 

■  develop  product  requirements 

-  establ  i  sh  product  and  product-component  requi  rements 

-  al  locate  product-component  requi  rements 

-  identify  interface  requirements. 

■  analyze  and  validate  requirements 

-  establish  operational  concepts  and  scenarios 

-  establish  a  definition  of  required  functionality 

-  analyze  requirements 

-  analyze  requirements  to  achieve  balance 

-  validate  requirements 

-  validate  requirements  with  comprehensive  methods 

■  manage  requirements 

-  obtai  n  an  understandi  ng  of  requi  rements 

-  obtai  n  commitment  to  requi  rements 

-  manage  requirements  changes 

-  maintain  bidirectional  traceability  of  requirements 

-  identify  inconsistencies  between  project  work  and  requirements 


13  CM  Ml  is  registered  in  the  U.S.  Patent  and  T rademark  Office  by  Carnegie  Mellon 
University. 
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It  is  important  to  note  that  the  list  above  is  implicitly  specified  for  the  context  of  a 
particular  system.  It  is  not  necessarily  intended  to  be  applicable  to  an  SoS, 
although  such  a  perspective  may  be  (and  often  is)  taken. 
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D  Software  Blocking 


None  of  the  issues  identified  by  the  attendees  explicitly  referred  to  the  Army  soft¬ 
ware  blocking  policy.  However,  there  was  discussion  of  the  Army  software  block¬ 
ing  during  the  workshop.  It  is  clear  that  the  blocking  policy  plays  an  important 
role  in  facilitating  the  development  of  an  Army  approach  to  an  SoS.  As  one 
attendee  said,  "Software  blocking  has  become  the  agent  for  interoperability."  The 
SWB  policy  must  be  i  mpl  emented  by  all  PE  Os  and  PMs.  Some  background  on 
software  blocking  is  described  in  th  e  Army  Acquisition  Policy  and  theArmy  Soft¬ 
ware  Blocking  Pol  icy  documents  [DoA  03  and  DoA  01]. 

The  purpose  of  the  software  blocking  process  is  to  facilitate  the  development  and 
sustainment  of  systems-of-systems  interoperability  through  the  periodic  delivery 
of  a  collection  of  elements  to  the  operational  community.  It  can  be  viewed  as  an 
approach  to  the  integration  of  multiple  systems.  The  term  block  is  used  to 
describe  a  process  having  two  segments: 

1.  preparation 

During  this  segment  products  related  to  requirements  and  architecture  are 
developed.  A  key  product  is  the  development  and  approval  of  the  Block  Exe¬ 
cution  Management  Plan  (BEM  P).  The  segment  is  expected  to  take  18 
months  to  complete. 

2 .  software  dejd  op  men  t 

The  software  development  segment  begins  after  the  BE  M  P  has  been 
approved  and  is  managed  according  to  the  BEMP.  The  segment  is  complete 
when  the  software  development  for  the  systems  has  been  completed  and  certi¬ 
fication  of  the  block  (including  interoperability  and  system-of-systems  evalua¬ 
tion)  has  been  passed.  Nominally,  this  segment  is  expected  to  take  36  months 
to  compl  ete. 

A  software  block  refers  to  a  software  basel  i  ne  whi  ch  i  s  desi  gned  to  sati  sfy  the  set 
of  system-of-system  requirements  applicable  to  the  block.  Software  blocks  may 
overlap  to  provide  software  updates  fielded  every  18  months.  The  nature  of 
requirements  is  expected  to  be  addressed  in  the  preparation  phase  of  the  block. 
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There  is  a  relation  between  an  SoS  and  a  software  block.14  For  example,  as  we 
noted  on  page  20,  "system  engineering  must  be  done  from  a  system-of-systems 
perspective  in  accordance  with  the  software  blocking  policy  and  its  implemented 
processes." 

During  discussion  of  the  blocking  process,  several  points  were  noted  by  the 
attendees,  including: 

■  Software  blocking  is  a  voluntary  (unfunded)  process  and  there  is  a  lack  of 
enforcement  and  accountability. 

■  Software  blocking  has  not  focused  on  requirements  development. 

■  There  is  no  single  point  of  authority  for  control  of  a  block,  couched  as  the  lack 
of  a  "trail  boss." 

■  There  is  no  M  ilestone  Decision  Authority  (M  DA)  for  a  block. 

■  Who  i  s  i  n  charge  of  writi  ng  requi  rements  for  an  SoS? 

■  It  is  not  clear  that  there  is  a  system  engineer  for  a  block.  The  closest  organiza¬ 
tion  for  this  would  be  G6,  but  they  might  not  have  the  knowledge  and  time  to 
perform  the  activity. 

■  Software  blocking  operates  in  a  pair-wise  manner  between  systems  to  negoti¬ 
ate  interoperability.  This  approach  is  better  for  hardware  than  with  data  and 
operational  semantics  that  apply  to  the  software.15 

No  doubt,  some  of  the  points  raised  may  reflect  the  relative  newness  of  the  appli- 
cati  on  of  the  software  bl  ocki  ng  pol  i  cy.  H  owever,  al  I  of  these  i  ssues  are  consi  stent 
with  ones  identified  earlier  in  the  workshop. 

It  is  not  the  intent  of  this  report  to  go  into  details  of  the  Army  software  blocking 
policy  per  seor  the  manner  in  which  it  is  implemented.  However,  some  of  the 
issues  identified  have  a  direct  bearing  on  the  concepts  associated  with  a  software 
block.  I  n  particular,  we  refer  to  the  issues  dealing  with  a  lack  of  system  engineer¬ 
ing  and  requirements  management  at  a  level  above  a  program  and  the  lack  of  sys¬ 
tem-of-systems  policies  and  funding  streams.  A  software  block  must  address 


14  We  make  no  distinction  here  between  a  system  of  systems  and  a  family  of  systems, 
which  was  brought  up  in  Section  1  and  discussed  further  in  Appendix  A. 

15  An  example  of  the  difficulties  that  may  arise  was  pointed  out  by  an  attendee  concern¬ 
ing  the  development  of  a  Combat  Status  Report.  Consider  the  amount  of  fuel  left  in  an 
aircraft.  One  participant  would  prefer  that  this  information  be  displayed  by  a  simple, 
color-coded  scheme  of  red,  yellow,  and  green.  Another  participant  would  prefer  toseea 
quantitative  measure,  such  as  how  many  gallons  of  fuel  are  left  or  how  long  the  fuel 
will  last.  These  preferences  represent  different  interpretations  of  the  same  data  by  dif¬ 
ferent  user  communities. 
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issues  just  such  as  these.  Further  study  of  the  software  blocking  policy  is  ongoing 
by  SEI  staff  with  special  emphasis  on  lessons  learned  from  the  execution  of  the 
first  increment  of  a  software  block. 
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E  Discussion  of  Pattern  Development 


M  uch  of  the  post-workshop  analysis  was  based  on  development  of  patterns  and 
anti  patterns,  terms  discussed  in  Section  4.  This  Appendix  provides  further  dis¬ 
cussion  and  an  example  of  a  pattern  development. 


E.1  Discussion 

Because  we  sought  a  simple,  systemati c  form  to  represent  issues,  we  chose  to  use 
patterns  and  anti  patterns.  Representing  a  pattern  in  the  form  <AV  A2;  R>,  where 
Ax  and  A2  represent  actors,  and  R  describes  the  relation  between  them,16  provided 
the  necessary  notation. 

Recall  that  the  issues  were  elicited  in  the  form  of  a  condition-consequence  pair. 
Both  the  condition  and  consequence  aspects  of  an  issue  can  be  represented  as  pat¬ 
terns.  Hence,  to  the  extent  that  a  condition  implies  a  consequence,  that  implica¬ 
tion  may  be  carried  over  to  the  representation  of  a  pattern  implying  another 
pattern. 

The  process  of  developing  patterns  often  involved  dealing  with  compound  state¬ 
ments.  As  an  example,  consider  the  statement  "System_X  and  System_Y  interop¬ 
erate  with  System_Z."  It  is  obvious  that  this  statement  is  really  the  combination 
of  two  more  basic  patterns,  namely  <System_X,  System  Z;  interoperate>  and 
<System_Y,  System_Z;  interoperate>. 

Of  special  importance  to  the  workshop  was  the  fact  that  we  sought  to  identify 
issues  raised  by  the  attendees.  The  use  of  anti  patterns  is  especially  relevant  when 
textual  statements  are  couched  as  issues.  That  is,  an  issue  typically  includes  a 
statement  that  is  critical  of  something  or  indicates  the  absence  of  something.  For 
example,  the  issue  'The  PMO  does  not  perform  system  engineering"  asserts  a 
negation  of  the  PMO  performing  system  engineering.  Glancing  over  the  list  of 

16  The  relation  among  actors  is  typically  expressed  as  a  verb.  Sometimes  in  presenting 
the  patterns,  or  their  use  in  a  context  map,  a  shorthand  notation  can  be  used.  For 
example,  the  statement:  'The  system  requirements  are  not  clear"  would  be  represented 
in  a  shorthand  form:  <system,  requirements,  clear>.  Thus,  for  simplicity  we  do  not 
include  the  more  correct  are  clear  as  it  is  implied. 
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issues  in  Section  3,  you  will  recognize  the  importance  of  the  use  of  anti  patterns  to 
the  discussion  of  issues  collected  at  the  workshop.  In  fact,  it  is  issues,  represented 
as  anti  patterns,  that  often  provide  very  useful  information. 

We  emphasize  again  our  need  to  have  a  simple,  systemati c  form  for  the  represen¬ 
tation  of  issues  identified  by  the  attendees.  The  use  of  patterns  proved  to  meet 
that  need.17  The  fact  that  there  is  a  direct  relation  between  a  pattern  and  some 
aspect  of  a  context  map  proved  all  the  more  valuable  in  the  development  of 
themes  involving  multiple  issues. 


E.2  Example 

The  foil  owing  illustrates  the  development  of  patterns  based  on  issues  identified 
by  the  attendees.  We  will  only  consider  the  case  of  those  issues  related  to  joint 
considerations  (discussed  in  Section  4.5).  The  development  of  other  patterns  is 
similar. 

I  ssue  10  identified  at  the  workshop  was  stated:  'TheJ  Cl  DS  process  has  no  path 
that  leads  to  a  view  (architecture)  that  can  be  used  for  a  statement  of  specification 
for  a  material  developer  or  test  criteria  by  the  combat  developer;  there  is  no  direct 
link  from  requi rements  to  end  product."  F rom  thi s  text,  the fol I owi ng  patterns 
were  developed: 

<architecture.  JCIDS  process;  results  from> 

<Material  Developer,  architecture;  uses> 

<Material  Developer,  specification;  creates> 

<Combat  Developer,  architecture;  uses> 

<Combat  Developer,  test  criteria;  creates> 

<test  criteria,  testing;  used  in> 

Notice  that  in  developing  these  patterns  it  was  necessary  to  also  include  a  pattern 
to  indicate  that  test  criteria  are  used  in  testing.  This  pattern  will  be  used  to  help 
integrate  the  pattern  from  issue  22,  discussed  below.  Recall  that  the  presence  of 
an  underscore  denotes  negation  of  the  indicated  expression. 

Issue  18  was  'There  is  a  lack  of  J  oint  Vision  (e.g.,  NCOW-RM)  and  a  system-of- 
systems  organization  structure;  leads  toward  a  stovepipe  development." 


17  There  is  more  that  can  be  done  for  a  pattern  approach.  Transforming  a  textual  state¬ 
ment  into  the  logical  conjunction  of  the  (more  basic)  patterns  is  but  one  example.  We 
have  not  attempted  to  bring  a  more  formal  approach  (e.g.,  grammar  and  calculus)  to 
the  use  of  patterns  constructed  in  this  workshop. 
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The  foil  owing  patterns  are  identified: 


<Joint  Vision.  SoS;  applies  to> 

<SoS,  SoS  Organization  structure,  based  on> 

<Stovepipe,  Organizational  structure;  type  of> 

I  ssue  22  was  "J  oint  system-of-systems  requirements  are  not  clear;  interoperabil¬ 
ity  is  not  guaranteed  and  joint  testing  results  are  questionable."  The  foil  owing 
patterns  were  developed: 

<SoS,  Joint  Requirements;  clear> 

<SoS,  interoperability;  auaranteed> 

<SoS,  joint  test  results;  questionable> 

When  the  preceding  patterns  are  combined,  we  have  the  overall  diagram  shown 
in  Figure  14.  The  dark  boxes  with  white  text  are  related  to  condition  clauses  asso¬ 
ciated  with  the  issues.  Normally,  a  context  diagram  will  not  be  presented  in  this 
highlighted  manner;  it  is  done  here  simply  as  an  aid  to  the  reader.  F  urther  discus¬ 
sion  of  this  diagram  appears  in  Section  4.5  beginning  on  page  20. 


Figure  14:  Summary  of  Joint  Issue  Relations 
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Acronyms 


A2C2S 

AOA 

ASA/ALT 

BEMP 

CM  M I 

COTS 

DCD 

FAR 

FoS 

G3 

G5 

G6 

G7 

G8 

I  CD 
ISIS 
J  Cl  DS 
J  ROC 
M  DA 

NCOW-RM 

OSD 

PEO 

PPBES 

PM 

PMO 

TOC 


Army  Airborne  Command  and  Control  System 
Analysis  of  Alternatives 

Assistant  Secretary  of  the  Army  for  Acquisition,  Logistics,  and  Technology 

Block  Execution  Management  Plan 

Capability  Maturity  Model  I  ntegration 

Commercial  off-the-shelf 

Directorate  of  Combat  Developments 

Federal  Acquisition  Regulations 

Family  of  Systems 

Army  Deputy  Chief  of  Staff,  responsible  for  development  of  policy  and  guidance 
for  requirements,  including  operational  requirements  process. 

Army  Recruiting  Command  Directorate 

Office  of  the  Army  Chief  I  nformation  Officer 

Army  Materiel  Command 

Army  Deputy  Chief  of  Staff,  responsible  for  programming,  materiel  integration, 
studies  and  analyses,  and  external  reviews. 

I nitial  Capabilities  Document 

I  ntegration  of  Software-1  ntensive  Systems 

J  oint  Capabilities  Integration  and  Development  System 

J  oint  Requirements  Oversight  Council 

Milestone  Decision  Authority 

Network  Centic  Operations  and  Warfare  —  Reference  Model 
Office  of  the  Secretary  of  Defense 
Program  Executive  Office 

Planning,  Programming,  Budgeting,  and  Execution  System 
Program  Manager 
Program  Management  Office 
Tactical  Operations  Center 
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PMO  Program  Management  Office 

SEMP  System  Engineering  Master  Plan 

SoS  System  of  Systems 

SoSAMO  System-of-Systems  Acquisition  Management  Organization 

SOSI  System-of-Systems  I  nteroperabi  I  ity 

SoSRMO  System  of  Systems  Requirements  Management  Organization 

SWB  Software  Blocking 

TOC  Tactical  Operations  Center 

TP  10  TRADOC  Program  Integration  Office 

TRADOC  Training  and  Doctrine  Command 

TSM  TRADOC  System  Manager 

U  SAAWC  U.  S.  Army  Aviation  Warfighting  Center 
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